Towards Architectural Programming of Embedded Systems

Integrating architectural elements with a modern programming language is essential to ensure a smooth combination of architectural design and programming. In this position statement, we motivate a combination of architectural description for distributed, asynchronously communicating systems and Java as an example for such an integration. The result is an ordinary programming language, that exhibits architecture, data structure and behavior within one view. Mappings or tracing between different views is unnecessary. A prototypical implementation of a compiler demonstrates the possibilities and challenges of architectural programming. 1 Java with Architectural Elements As stated in [MT00] there are a number of languages that support design, analysis, and further development of software-system-architectures. These languages are commonly known as Architecture Description Languages (ADL) and allow a high level description of software systems of a specific domain. Using an ADL enables reasoning about specific system properties in an early development stage [GMW97]. Furthermore, there are quite often mappings from architecture to a General Purpose Language (GPL), producing code frames for the GPL. This helps ensuring the architectural consistency initially, but when the code evolves the architecture becomes implicitly polluted or when the architecture shall be evolved this needs to be done on the code level. Tracing is therefore important to keep architecture and code aligned. However, it would be much better to integrate both, architecture and code into one single artifact such that tracing is not necessary anymore. [MT00] defines a component as a unit of computation or storage that may represent the whole software system or just a single small procedure. Components in distributed systems partially run in a distributed manner on different hardware. As a consequence they do not share memory and the communication through shared variables or ordinary method calls is not feasible. So they communicate with each other through channels called connectors by asynchronous message passing. Here a component always has an explicitly defined interface of needed and offered connectors. In contrast to this, object oriented classes respectively their instances in a GPL are mostly accessed through their implemented interfaces synchronized by blocking method calls. But a class does not explicitly describe the interfaces it uses. In addition, the hierarchical containment that is intensely used in ADLs to structure systems, is almost completely missing in the object oriented paradigm. A common way to structure object oriented systems is the usage of packages. However [HRR10] A. Haber, J. O. Ringert, B. Rumpe. Towards Architectural Programming of Embedded Systems. In: Tagungsband des Dagstuhl-Workshop MBEES: Modellbasierte Entwicklung eingebetteter Systeme VI. Informatik-Bericht 2010-01, Institut für Software Systems Engineering, TU Braunschweig, 2010 www.se-rwth.de/publications one is not able to express hierarchical containment with this technique. Several approaches like JavaBeans [JB09] enrich an existing GPL with a component concept. Nevertheless they do not exceed or extend the borders drawn by the target object oriented GPL. These approaches mainly introduce new libraries written in plain GPL code or map a language extension into the original GPL. Doing so, Java has been enriched by JavaBeans with a concept to use components in an object oriented environment, but the traceability from architecture to code has not been increased very much. And this traceability is necessary, because the developer is exposed with both views, the architecture and the code. We believe that one way to raise this traceability respectively to make it unnecessary is to combine an existing ADL with a common GPL in such a way that architectural definitions are explicit and essential part of the language. We decided to use the ADL MontiArc that resembles a common understanding of how to model distributed communicating systems, similar to automotive function nets [GHK07], or UML’s composite structure diagrams [OMG07], and with a precise underlying calculus like FOCUS [BS01] as described in Sect. 4. As our target GPL we decided to use Java, because it is a widely accepted modern language. We integrate classes, methods, and attributes into components. This gives us a new programming language with the working title “AJava” and enables us to combine concrete behavior descriptions with an abstract high-level architectural description directly in one artifact. Enhanced with a syntax highlighting Eclipse-editor that supports functions like auto-completion, folding, error messages, and hyperlinking to declarations, one is able to program architectures in a familiar and comfortable development environment. Further tool support is given by a prototypical compiler for a subset of AJava based on the DSL framework MontiCore [GKR08]. The concrete syntax of AJava will be shown in the next section with an introducing example. In Sect. 3 we discuss aspects of the design and variations of AJava. Our approaches to building a compiler and defining semantics are presented in Sect. 4. This paper ends with related approaches and a conclusion in sections 5 and 6. 2 Integrated Component Programming As an example of how to model and implement an embedded system in AJava we present a coffee machine which takes the selection of a type of coffee as input. Connected to the machine is a milk dispenser which is managed by the coffee machine specifying the needed amount of milk and receiving an error signal if the milk tank is empty. The coffee machine itself is composed of a display, the coffee processing unit and bean sensors to monitor the available amount of coffee and espresso beans. A graphical representation of the main component is given in Fig. 1. Its corresponding implementation in AJava is given in listing 1. Please note that the textual representation is covering all features in Fig. 1, although some connectors are not explicitly given but derived from the component’s context. We assume, regarding the development process, that appropriate editors show the textual representation as main development artifact and the